Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

We will need you to sign the CLA before we can review this change.

We will need you to sign the CLA before we can review this change.

CLA signed

Just a warning that the best person to review this is out for a bit, so you should expect silence for at least a week

@Okapist these are some intriguing results. Thank you for trying this out!

Before we go down this path of introducing complexity through splitting and continue to expand the size of generated message code, I'd like us to try comparing the performance using the Lite approach to these methods.

See GeneratedMessageLite.hashCode, .equals, .writeTo which use the Schema utility to implement these methods.

Would you be willing to take a crack at that for comparison? I have a pressing project that will likely delay me from investigating that approach myself. The goal is to balance performance with the maintenance load from having so many approaches to the problem.

Yep.
No changes. It's generates the absolutely same java code for MessageLite. There no big methods generation in lite approach.

Performance check show no difference as expected.

Benchmark                     Mode  Cnt    Score   Error  Units
Test.checkNew70fieldsWriteTo  avgt    2  810,307          ns/op
Test.checkOld70fieldsWriteTo  avgt    2  835,257          ns/op

Benchmark                       Mode  Cnt     Score   Error  Units
Test.checkNew70fieldsRoundtrip  avgt    2  1842,443          ns/op
Test.checkOld70fieldsRoundtrip  avgt    2  1968,669          ns/op

Benchmark                    Mode  Cnt  Score   Error  Units
Test.checkNew70fieldsEquals  avgt    2  0,822          ns/op
Test.checkOld70fieldsEquals  avgt    2  0,889          ns/op

@Okapist Thanks for running this!

If I understand, these are results for running the other methods with the split in place. Which will be useful for the comparison I really want to run which is using the Lite implementation of these methods vs current impl and split impl.

We could then decide if we should introduce splitting or use the Lite implementation.

Lite implementation is slow. Usually we use serialize and deserialize only. Lite is 20-30% slower than normal.
Use normal implementation for all cases except big proto is frustrating and hard to support.

@Okapist @googleberg Hi, I would like to know the current status of this PR. Has the ability of autosplitter been integrated? I think this feature is still very important. Big proto will seriously affect the performance of serialization and deserialization in Java. Even if you encounter a proto with too many lines and the generated java method exceeds 64k, it cannot be used at all.